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Abstract  -  The  authors  are  developing  enhanced  onboard 
and  at-wing  diagnostic  technologies  applicable  to  both  legacy 
and  new  avionics.  The  paper  identifies  onboard  information 
sources  and  automated  reasoning  techniques  that  build  upon 
existing  Built-in-Test  (BIT)  results  to  improve  fault  isolation 
accuracy.  Modular  software  and  data  elements  that  combine 
BIT  with  contextual  information,  component  usage  models, 
and  novel  reasoning  techniques  are  described.  In  addition,  the 
authors  identify  candidate  avionics  component  applications  to 
implement  prognostics  (prediction  of  impending  problem) 
using  forecasting  techniques.  A  demonstration  of 
diagnostic/prognostic  prototype  reasoners  and  information 
continuity  using  an  open  architecture  framework  within  the 
streamlined  maintenance  concept  is  offered. 

I.  Introduction 

Avionics  systems  are  diverse,  with  developments 
spanning  decades,  but  they  can  be  broadly  classified  as 
legacy  ‘federated’  and  modular  ‘integrated’  systems. 
Legacy  avionics  systems,  comprised  of  many  stand-alone 
replaceable  units  connected  in  a  ‘federated’  architecture,  are 
successful  from  a  flight  performance  and  functionality 
perspective  but  possess  limitations  for  fault  isolation  and 
root  cause  diagnoses.  Current  statistics  of  cannot  duplicate 
(CND)  and  no-fault-found  (NFF)  indicate  the  need  for 
improvements.  The  design  of  newer,  integrated,  modular, 
backplane  digital  electronics  provides  a  direct  opportunity 
for  better  diagnostic  and  ambiguity  reduction  through  a 
better  understanding  of  system  dependencies.  Onboard  and 
at-wing  upgrades  that  include  the  capture  and  fusion  of  1) 
operating  conditions;  2)  input  and  output  parameter  sets  3) 
environmental  data;  and  4)  diagnostic  and  prognostic  model 
results  can  provide  significant  benefits. 

Current  military  avionics  diagnostic  and  repair  processes 
suffer  a  large  degree  of  error  [1,2].  CND,  RTOK,  NFF,  or 
otherwise  cannot  verify  (CNV)  statistics  range  to  as  high  as 
50  to  75  percent  [2].  The  net  result  of  this  problem  is  a 
maintenance  and  logistics  infrastructure  that  must  sustain 
substantial  overhead  in  order  to  support  replacement  of 
equipment  that  may  not  be  faulty  [3].  Another  effect  of  this 
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loss  of  repair  and  maintenance  accuracy  is  degraded  overall 
mission  readiness.  The  problem  has  been  extensively 
studied  and  there  exist  many  current  attempts  to  mitigate 
errors  in  the  process.  These  attempts  range  from  the  overall 
design  and  implementation  of  new  ideas  within  future 
integrated  avionics  systems  down  to  the  incorporation  of 
reconfigurable  test  suites  for  current  and  legacy  avionics 
systems.  Some  enabling  technologies  include  the 
development  of  an  automated  test  meta-language  (ATML) 
[4],  the  development  of  open  systems  automated  test 
equipment  through  the  Agile  Rapid  Global  Combat  Support 
(ARGCS)  joint  initiative  [5],  the  implementation  of 
sophisticated  at  wing  systems  stimulation  [3],  and  the 
exploration  of  the  feasibility  of  providing  onboard 
embedded  diagnostics  for  legacy  avionics  systems. 

The  authors  are  developing  several  technologies  for 
enhanced  onboard  fault  isolation  and  scenario  recreation  for 
offboard  verification  applicable  to  both  broad  classes  of 
avionics.  Specifically,  the  current  paper  identifies  onboard 
information  sources  and  automated  reasoning  techniques 
that  build  upon,  but  are  not  limited  to,  Built-in-Test  (BIT) 
results.  The  specific  diagnostic  and  prognostic  modules  are 
constructed  using  open  system  software  architecture  tenets, 
and  a  specific  extensible  Markup  Language  (XML)  schema 
representation  was  adopted.  This  design  provides  greater 
flexibility  within  a  platform  application  to  place  the 
reasoning  at  multiple  levels  in  the  diagnostic  chain: 
onboard,  at-wing,  and  remote  depot.  It  also  enables  greater 
reusability  across  multiple  platforms,  which  will  reduce  the 
need  for  totally  dedicated  software  development  or  test 
equipment  for  each  platform. 

II.  Avionics  Classification 

A.  Legacy  ‘Federated’ Systems 

The  term  federated ,  used  to  describe  traditional  avionics, 
means  each  LRU  is  an  independent  unit  possibly  made  by 
different  manufacturers,  and  potentially,  varying 
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technology.  Each  manufacturer  provides  diagnostic 
capability  for  each  LRU  in  the  form  of  a  built  in  test  (BIT), 
automated  test  equipment  (ATE),  and  test  program  sets 
(TPS).  In  addition,  separate  interactive  electronic  technical 
manuals  (IETMs)  may  or  may  not  be  provided.  All  of  the 
independent  LRUs  are  expected  to  function  side  by  side  in  a 
largely  autonomous  fashion  to  provide  the  total  system 
functionality  required  to  fulfill  the  aircraft’s  mission.  It  is 
this  integration,  albeit  loose,  and  its  potential  system  level 
effects  that  are  not  typically  considered  by  the  current 
maintenance  infrastructure. 

B.  Modular  ‘Integrated’ Systems 

Integrated  Modular  Avionics  (IMA)  is  an  emerging 
design  approach  that  seeks  to  maximize  the  benefits  of 
system  interconnectivity  gained  by  providing  common 
interfaces  to  components  in  the  avionics  systems.  Military 
examples  include  the  F-22  Advanced  Tactical  Fighter,  the 
F-35  Joint  Strike  Fighter,  and  the  RAH-66  Comanche 
helicopter.  Many  benefits  are  provided  in  these  designs  such 
as:  system  redundancy,  situational  awareness,  real  time 
diagnosis,  and  dynamic  reconfiguration.  In  short,  they  are 
designed  with  more  consideration  of  the  overall  system  and 
its  dynamics  [5]. 

Integration  is  achieved  through  architectures  ranging  from 


benign  message  passing  on  a  bus,  where  the  failure  of  one 
LRU  simply  means  that  results  won’t  be  completely 
accurate,  to  complete  level  integration  where  a  global 
controller  (software,  hardware,  or  a  combination  of  both) 
assembles  all  data  for  manipulation  and  display  [3,5]. 

III.  Avionics  Maintenance  Operational  Concept 

A  comprehensive  diagnostic  and  prognostic  capability  for 
avionics  system  components  builds  upon  enabling 
technologies  such  as  built-in-test,  advanced  health 
monitoring  algorithms,  reliability  and  component  aging 
models,  prognostics  methods,  and  knowledge  discovery 
tools. 

An  overall  operational  concept  is  pictured  in  Figure  1.  A 
paradigm  shift  from  the  onboard  data  capture  to  the 
logistical  infrastructure  will  best  maximize  the  opportunity 
presented  by  embedded  avionics  diagnostics  and 
prognostics  technologies  being  developed.  The  operational 
concept  illustrates  the  streamlining  of  the  three-tiered 
maintenance  structure  with  system  and  component  analysis 
occurring  onboard  and/or  at-wing.  This  evolution,  through  a 
multi-step  process,  of  current  methods  is  supported 
throughout  evolving  vehicle  health  management  (VHM) 
system  framework.  From  more  accurate  at-wing  diagnostics 
to  the  measurable  enhancements  that  prognostics  can 
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Figure  1  -  Operational  Concept  for  Embedded  Diagnostics/Prognostics  and  Picture  of 

Future  Implementation 


provide  for  the  logistical  support  structure,  the  data  driven 
architecture  described  here  can  serve  as  the  foundation  and 
core  support  to  enable  such  a  paradigm  re-alignment.  An 
“open  data”  architecture  will  be  critical  to  ultimate 
deployment  and  acceptance. 

This  framework  and  vision  is  consistent  with  the  onboard 
PHM  (Prognostic  and  Health  Management)  as  well  as 
advanced  Automated  Test  Equipment  (ATE)  approaches 
such  as  the  Agile  Rapid  Global  Combat  Support  (ARGCS) 
system.  The  future  PHM  designs  will  make  optimal  use  of 
the  predictive  information  using  the  autonomic  logistics 
information  system.  The  ARGCS  goal  of  software 
interoperability  will  also  be  enabled  by  the  open  data 
architecture  proposed  to  automatically  recompile  the  TPS 
(Test  Program  Set)  for  different  applications  [5]. 

The  field  is  diverse.  Opportunities  to  integrate  an 
embedded  avionics  PHM  system  are  numerous.  Some  of  the 
earliest  opportunities  may  come  in  the  arena  of  legacy 
system  upgrades.  Federated  components  operating  together 
within  an  aircraft  share  many  common  bonds  and  can  affect 
each  other  in  ways  that  can  be  detected  globally.  Power 
systems,  data  busses,  environmental  factors,  and  wiring 
infrastructures  are  examples  of  some  of  these  common 
bonds.  The  interactions  among  these  factors  create 
confounding  issues  to  diagnostic  systems  that  are  not 
accounted  for  in  LRU  built-in-tests  or  at  any  other  level  of 
the  maintenance  infrastructure.  From  a  global  perspective 
this  symbiotic  “systems”  relationship  can  provide  a  large 
opportunity  to  collect  evidence  that  can  be  used  to  diagnose 
faults  and  predict  failures.  Rather  than  confounding,  these 
relationships  can  be  used  to  an  avionics  health  management 
system’s  advantage  to  lower  the  total  life  cycle  cost  (LCC) 
associated  with  the  avionics  system. 

IV.  Onboard  Evidence  Sources 

Impact,  with  the  assistance  of  Honeywell,  sought  to 
identify  data  that  could  be  used  in  the  implementation  of  an 
on  board  avionics  health  management  system  and  evaluate 
its  evidentiary  importance  to  the  provision  of  a  robust 
diagnosis  and  prognostic  update.  These  factors  will  drive 
the  implementation  of  the  diagnostic/prognostic  system.  A 
detailed  explanation  of  these  evidence  sources  is  given  here. 

A.  Time  Stamp 

Correlation  in  time  is  the  most  obvious  deficiency  in  the 
current  federated  avionics  diagnostic  approach.  While 
length  of  operation,  or  time  since  the  last  event,  may  be 
available  to  the  BIT,  there  is  typically  no  absolute  time 
record  recorded.  Valuable  information  regarding  operational 
parameters,  global  system  behavior,  related  component 
behavior,  and  myriad  other  possible  related  factors  can  best 
be  correlated  in  true  time.  This  time  record  allows  the 
discovery  of  causal  relations  and  thus,  is  imperative. 


B.  System  Power 

All  electronic  systems  require  stable  power  supplies  that 
operate  within  regulated  parameters.  Operation  outside 
these  parameters  for  extended  periods  of  time  or  even 
momentary,  at  extreme  conditions,  can  cause  premature 
failure  of  electronic  components.  In  order  for  an  effective 
prognostic  system  to  be  implemented,  all  major  factors  that 
will  affect  a  component’s  remaining  useful  life  should  be 
monitored.  In  addition  to  the  prognostic  forecasting 
capabilities  provided  by  monitoring  system  power,  multiple 
confounding  errors  by  electronic  components  can,  quite 
often,  be  correlated  with  global  power  problems. 

C.  Temperature  of  LRU/SRU 

Thermal  activity  can  be  utilized  as  an  indicator  of 
LRU/SRU  functionality  and  current  health  state.  Electronic 
components  have  normal  operating  temperature  ranges 
specified  by  the  manufacturer.  Operation  outside  of  these 
ranges  dictates  a  possible  update  of  the  component  model 
regarding  remaining  useful  life  in  order  to  provide  accurate 
prognostic  output.  This  also  represents  a  stress  to  the  system 
that  can  be  accounted  for  using  the  model-based  diagnostics 
and  prognostics  approaches. 

D.  Vibration  LRU/SRU 

Physical  shock  and  excessive  vibration  are  known  to  have 
detrimental  effects  on  electronic  equipment.  These 
parameters  should  be  monitored  and  exceedances  recorded 
to  provide  input  to  the  diagnostic  reasoner  or  update  the 
prognostic  model.  Failing  cooling  fans,  oscillating 
transformers,  loose  and  vibrating  components,  and  other 
failures  or  precursors  can  be  more  readily  identified. 

E.  Power  LR  U/SR  U 

Component  power  fluctuation  that  does  not  correlate  with 
global  system  power  anomalies  can  be  used  to  indicate  and 
pinpoint  individual  LRU/SRU  failure  as  well  as  indicate 
possible  wiring  system  problems.  Correlation  of  local  power 
anomalies  at  the  LRU/SRU  level  can  help  pinpoint  the 
source  of  wiring  problems  or  other  factors  causing  the 
anomaly. 

F.  BIT  Error 

Built-in-test  error  codes  provide  a  data  recording  trigger 
as  well  as  a  starting  point  for  problem  diagnosis.  It  is  quite 
likely  that  with  correlation  in  time  to  all  other  sources  of 
evidence,  some  number  of  BIT  errors  will  be  deemed 
spurious  or  caused  by  other  external  interactions.  However, 
in  the  event  of  actual  LRU/SRU  failure,  these  errors  remain 
as  a  key  insight  to  the  manufacturers  design  expectations 
through  the  associated  BIT  error  logic. 

G.  Design  Logic  of  BIT  Errors 

Design  criteria  are  used  to  set  an  actual  BIT  error.  In 
order  for  the  error  message  to  be  activated,  certain 
conditions  have  been  met  for  certain  periods  of  time.  These 
conditions  and  thresholds  can  serve  as  evidence  that 


provides  a  higher  order  understanding  of  events  at  the 
system  level. 

H.  LRU  Analog  Inputs 

Many  legacy  systems  use  various  analog  inputs  to 
controllers.  The  inputs  noise  level  existing  on  these  may  or 
may  not  be  monitored  by  BIT.  In  the  case  that  it  is  not, 
monitoring  and  low-level  reasoning  is  appropriate  to 
provide  more  detail  level  inputs  to  the  VHM  system. 

/.  LR  U/SR  U  Reliability 

Component  lifing  data  begins  with  the  reliability  data 
provided  by  the  design  engineer  and  is  further  refined 
through  reliability  growth  models  developed  during  a 
system’s  lifetime.  This  data  serves  as  a  basis  for  the 
construction  and  maintenance  of  individualized  component 
models  that  are  then  updated  to  account  for  local 
exceedances.  While  probability  models  cannot  describe 
discrete  cases,  they  can  be  used  to  provide  predictions  of 
remaining  useful  life  and  assess  confidence  values  to 
diagnostic/prognostic  outputs. 

J.  LRU/SRU Life  History 

An  LRU/SRU  can  be  tracked  throughout  its  initial 
installation  and  life  history  as  it  is  migrated  from  system  to 
system  through  failures  and  repair  within  the  logistics 
apparatus.  Such  tracking  can  detect  rogue  units,  provide 
accurate  update  date  to  component  life  models  and  assist  in 
the  development  of  a  repair  effectiveness  tracking  system. 

K.  LR  U/SR  U Logistics  Considerations 

The  diagnostic  output  will  be  a  ranked  list  of  maintenance 
actions.  The  intelligent  maintenance  system  will  also 
consider  the  available  spares  and  equipment  required  to 


further  prioritize  a  timely  repair. 

These  evidence  sources  comprise  the  fundamental  basis 
for  a  robust  diagnostic  and  prognostic  health  management 
system.  This  basis  is  used  to  derive  specific  design  solutions 
for  embedded  avionics  to  affect  positive  impact  to  the 
current  maintenance  system.  Methods  to  capture  such  data 
in  an  open  format  to  enable  greater  portability  are  addressed 
next. 

V.  Information  Transformation  and  Data 
Continuity 

Openness  is  a  general  concept  that  denotes  free  and 
unconstrained  sharing  of  information.  In  its  broadest 
interpretation,  the  term  “open  systems”  applies  to  a  systems 
design  approach  that  facilitates  the  integration  and 
interchangeability  of  components  from  a  variety  of  sources. 
For  a  particular  system  integration  task,  an  open  systems 
approach  requires  a  set  of  public  component  interface 
standards  and  may  also  require  a  separate  set  of  public 
specifications  for  the  functional  behavior  of  the 
components.  The  underlying  standards  of  an  open  system 
may  result  from  the  activities  of  a  standards  organization 
(e.g.  IEEE),  an  industry  consortium  team  (e.g.  OSA-CBM), 
or  may  be  the  result  of  market  domination  by  particular 
product  (or  product  architecture). 

An  open  system  approach  to  automated 
diagnostics/prognostics  begins  with  a  functional 
decomposition  of  the  various  evidence/data  sources  and 
dissection  of  the  logical  points  for  system  data  exchange. 
The  goal  is  to  describe  a  system  architecture  that  permits  the 
access  by  many  diverse  component/software  suppliers  to  all 
aspects  of  the  system.  This  must  be  done  in  a  manner  that 
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Figure  2  -  XML  Data  Insertion  to  Database 


does  not  constrain  the  performance  of  the  prognostics  health 
management  system.  The  end  result  should  be  defined 
system  output  formats,  software  module  input  formats,  and 
minimal  set  of  performance  specifications. 

Impact  Technologies  explored  and  demonstrated  open 
information  exchange  between  onboard  hardware,  various 
available  off-board  data  sources,  and  various  avionics  health 
management  (AHM)  software  components.  An  open  data 
architecture  facilitates  information  continuity  throughout  the 
onboard  and  off-board  AHM  system  by  encapsulating  a 
standard  of  what  information  (system  id,  sensor/LRU/SRU 
information,  data  collection  parameters,  etc.)  will  be 
represented  by  the  information  stream  and  a  standardized 
meta-data  description  of  what  the  individual  data  elements 
represent.  Two  examples  of  open  systems  approaches  are 
AI-ESTATE  and  OSA-CBM.  Automatic  Test  Meta 
Language  (ATML)  committee  of  IEEE  is  exploring  the 
development  of  an  XML  standard  for  automated  test 
equipment  (ATE).  Currently  available  OSA-CBM  protocols 
describe  an  open  standard  for  data  collection,  condition 
monitoring,  and  maintenance  information  exchange. 

The  research  team  chose  OSA-CBM  as  the  model  for  a 
prototype  implementation  due  to  the  diverse  experience  that 
Impact  Technologies  has  accrued  with  design  and 
implementation  of  VHM  systems  based  on  this  protocol. 
OSA-CBM  describes  the  exchange  of  information  from  data 
collection  to  data  manipulation  as  well  as  diagnostic 
reasoning  and  health  assessment.  Modalities  described  by 
OSA-CBM  include  XML,  CORBA,  and  COM/DCOM  [7]. 
Impact  chose  to  implement  the  prototype  demonstration 
using  XML  data  streams  due  to  the  illustrative  mapping  of 
meta-data  (header  tags)  to  database  fields. 

An  OSA-CBM  wrapper  provides  a  means  for  any  data 


stream  to  be  wrapped  in  XML  and  sent  to  another  module. 
The  wrapper  will  be  in  a  standard  OSA-CBM  format.  This 
standard  will  allow  the  data  to  be  sent  to  a  new  module  and 
easily  parsed  by  an  XML  wrapper  program.  Neither 
module  needs  to  know  what  the  other  is  doing.  The  only 
requirement  is  that  both  modules  can  parse  XML.  Several 
open-source  programs,  such  as  Jame’s  Clark’s  expat  and  the 
DOM  parser,  exist,  and  could  be  used  as  an  efficient  way  to 
parse  the  OSA-CBM  wrapper  [8].  Application  of  the  OSA- 
CBM  wrapper  technique  to  data  streams,  allows  for  a 
modular  program  design  with  an  ease  of  interchanging 
modules  from  different  sources. 

Output  from  many  available  data  capture  and  reasoner 
routines,  e.g.  BIT  and  BUS  monitors,  is  not  likely  to  be 
found  in  an  OS  A  format  specified  by  an  interchange 
schema.  An  OSA  wrapper  uses  local  translation  knowledge 
of  the  data  output  format  from  these  individual  sources  to 
convert  the  stream  to  verifiable  OSA  stream  [7].  To  create 
XML  output  that  conforms  to  a  schema,  the  wrapper  will 
employ  handlers  (Handlers  are  program  modules  that  enable 
the  schema  cross  validation  [8].)  to  interpret  the  incoming 
data  stream  and  provide  the  XML  tags  and  appropriate 
structure.  A  wrapper  makes  no  change  to  the  existing 
software,  but  provides  the  output  standardization  that 
preserves  situational  context  and  supports  information 
continuity. 

VI.  Automated  reasoning  Techniques 

A.  Bayesian  Belief  Network  (Nodal  Model) 

Impact  constructed  a  Bayesian  Belief  Network  (BBN)  to 
illustrate  a  top-level  system  reasoner  within  an  avionics 
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Figure  3  -  High-level  reasoning  using  a  Bayesian  Network 


Figure  4  -  Netica  BBN  (Airspeed  Sensor 
Example) 

VHM  system.  Several  Bayesian  Belief  Network  tools  are 
available.  Impact  used  Netica™  to  demonstrate  feasibility 
by  designing  a  prototype  nodal  system  to  describe  a  basic 
avionics  system.  The  example  system  contains  four  major 
LRUs  and  several  existing  avionics  input  units.  The  BBN, 
see  Figure  3,  describes  the  relationships  and  dependencies 
contained  within  the  system. 

Autopilot,  navigation,  communications,  and  pilotage  are 
the  four  major  LRUs  represented  by  the  BBN  in  Figure  4.  A 
communications  data  bus,  main  system  power  with  one 
additional  sub-circuit,  a  radio  frequency  antenna,  global 
position  sensor,  and  altitude,  attitude,  and  airspeed  sensors 
are  included  as  inputs  to  the  system.  The  arrows  and 
associated  truth  tables  describe  relationships  and 
dependencies.  For  example,  the  radio  frequency  antenna,  a 
root  node,  is  assigned  a  50/50  a  priori  probability  of 
functioning.  This  represents  no  system  design  reliability 
knowledge,  a  point  worth  keeping  in  mind.  A  portion  of  the 
communications  node  truth  table  is  dedicated  to  the 
representation  of  the  cause  and  effect  relationship  it  has 
with  the  antenna.  The  key  to  robust  utility  of  the  BBN  is  the 
initial  non-representation  of  design  reliability  knowledge  at 
the  nodes.  This  representation  can  come  later  as  a  part  of  a 
low-level  reasoning  process  that  uses  evidence  to  set  belief 
values  at  each  node  when  and  if  adequate  evidence  becomes 
available. 

B.  Evidence-Based,  At  Wing  Reasoning  Process 

Positive  and  Negative  Evidence,  along  with  Real  Fault 
Probabilities  and  False  Alarm  Rates  contribute  to  the 
Failure  Mode  Ranking  process.  Positive  Evidence  is  defined 
as  collaborative  indications  (LRU  status  or  signal  status) 
that  directly  indicate  failure  modes.  Negative  Evidence  is 
defined  as  the  absence  of  evidence  when  it  is  expected. 

Figures  5  and  6  present  the  use  of  the  at  wing  reasoner  for 
ambiguity  reduction.  In  the  first  figure  are  the  results  of  the 


onboard  embedded  diagnostics.  These  results  have  left  an 
ambiguous  diagnosis  where  four  LRUs  compete  for  ranking 
as  the  probable  cause  of  the  failure.  The  at  wing  reasoner 
will  use  this  embedded  diagnosis  as  an  input  and,  with 
knowledge  of  additional  testing  that  can  be  completed,  will 
suggest  an  optimal  path  for  ambiguity  reduction.  The  output 
after  evaluating  the  test  performed  and  resultant  clarification 


Figure  5  -  At  wing  Reasoning:  Initial 
Ambiguity  State 

is  illustrated  in  the  second  figure. 

The  use  of  this  at  wing  reasoner  with  LRU  self-test 
enhanced  by  at  wing  stimulation  is  one  major  step  in  the 
reduction  of  ambiguities  that  occur  at  wing.  These 
ambiguities  typically  result  in  the  pull-and-replacement  of 
two  or  three  LRUs.  Implementation  of  such  a  process  at 
wing  can  yield  an  obvious  large  reduction  process  error  by 
elimination  of  the  pull-and-replace  repair  process  that  is 
currently  executed.  The  recent  evolution  of  synthetic 


Figure  6  -  At  Wing  Reasoning  after  Correct 
Tests 


instrumentation  packaged  within  MIL-STD  28800  Class  1 
specs  will  facilitate  more  testing  and  diagnosis  at  the  wing 
and/or  forward  echelons. 

VII.  Legacy  Avionics  Implementation  Prototype 

For  the  purpose  of  demonstration  of  the  open  data 
approach  and  reasoner  functioning,  Impact  developed  a 
prototype  implementation  using  a  Honeywell  (C-130) 
Autopilot.  The  C-130  autopilot  is  a  prime  example  of  legacy 
system  with  analog  and  digital  inputs  operating  in  a 
federated  architecture.  There  exists  limited  diagnostic 
modeling,  and  the  C-130  autopilot  has  highly  developed 
BIT.  Moreover,  the  autopilot  touches  many  aspects  of  the 
avionics  system  and  gives  a  good  system  level  perspective. 

Within  the  demonstration,  the  autopilot  is  connected  to  a 
laptop  computer  via  a  MIL- 1553  interface.  Impact 
demonstrated  the  capture  of  BIT  and  fault  code  information, 
its  open  information  exchange  conversion,  and  its 
subsequent  synthesis  and  processing  of  as  would  be  capable 
onboard  or  at-wing. 


Figure  7  -  Demonstration  Setup 


Impact  wrote  an  OS  A  wrapper  to  translate  the  proprietary 
hexadecimal  stream  of  words  into  an  OS  A  data 
representation.  Figure  8  is  a  screen-capture  of  the  data 
extraction  and  conversion  module  developed  by  Impact 
Technologies  to  demonstrate  onboard  data  capture  to  off- 
board  availability  and  continuity.  In  the  module,  AFCP 
(Aircraft  Flight  Control  Processor)  data  is  received  via  the  C 
executable.  The  raw,  hexadecimal  data  is  converted  to  an 
XML  data  stream,  which  conforms  to  a  condition  monitor 
output  specification  defined  by  the  OSA-CBM  protocol 
version  1.0.2.  This  module  communicates  on  the  1553  data 
bus  using  a  PCMCIA  card  provided  by  Ballard  Technology. 
Ballard  provides  a  C  application  programmer’s  interface 
(API)  that  was  incorporated  into  Impact’s  module.  The  GUI 
implementation  was  developed  with  TCL/Tk  (Tool 
Command  Language).  The  XML  document  can  then  be 
viewed  using  an  Internet  web  browser. 

Impact  developed  a  Java  based  simulation  of  the  evidence 
processing  and  reasoning  portion  of  the  AHM  system, 
illustrates  the  flow  of  evidence  from  the  open  database 
through  a  data  broker  interface  to  various  low  level 
evidence  reasoners.  Results  are  then  routed  to  a  Bayesian 
Belief  Network,  Neural  Fuzzy  system  and  a  Dempster- 
Shafer  fusion  module  that  complete  the  system  level 
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Figure  8  -  Impact  1553  data  extraction  and 
XML  translation  module 

reasoning  process.  A  maintenance  report  is  output,  along 
with  updates  to  system  usage  models  and  reliability  models 
as  necessary.  A  description  of  three  scenarios  used  to 
exercise  the  system  is  presented  below. 

Scenario  1  describes  an  event  where  the  autopilot 
disengages,  due  to  an  air  speed  sensor  malfunction,  and  sets 
a  BIT  error.  In  the  case  of  the  C-130  autopilot,  the  air  speed 
sensor  data  is  an  input  from  the  ARINC  429  data  bus.  The 
BIT  error  would  only  indicate  that  there  was  a  problem  with 
the  429  interface.  This  indication  could  resolve  to  numerous 
possible  root  causes,  ranging  from  the  actual  sensor  problem 
to  an  internal  interface  problem  within  the  autopilot.  A 
system  level  reasoner  can  capture  the  knowledge  that  the 
data  bus  is  working,  power  is  good,  communications  is 
working,  the  global  positioning  system  is  working,  etc.,  and 
ultimately  resolve  the  root  cause  to  a  malfunctioning  air 
speed  indicator  to  a  confidence  of  above  80%. 
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Figure  9  -  Embedded  Avionics  Concept  Demonstration 


VIII.  Prognostics  Considerations 

There  fundamentally  exist  four  problem  types  within 
avionics  systems  (see  Figure  ).  Binary  faults  produce  very 
short  time  horizon  progression  from  operational  to  failed. 
Intermittent  problems  can  be  either  repeatable  with 
conditions  and  operational  modes  or  nearly  random.  Class  4 
problems  are  those  that  possess  more  gentle  progression 
rates. 

Prognostic  features  within  the  embedded  avionics  system 
include: 

■  Specific  component  prognostics  using  sub¬ 
circuit  component  model  (“weakest  link”) 

■  Health  state  tracking  for  graceful  degradation 
(Problem  Type  4) 

■  Fault  identification  diagnostics  with  association 
to  known  effects 

Outputs  from  the  avionics  prognostics  module  will  be 
useful  throughout  the  maintenance  and  logistics  system. 
Model  based  diagnostics/prognostics  update,  logistical 
planning,  and  evaluation  metrics  are  the  major  users  of  the 
outputs  of  the  prognostics  system.  The  outputs  of  a 
prognostic  system  will  take  the  form  of : 

■  Time  to  Failure  with  associated  confidence. 

■  Remaining  Useful  Life  or  operational  cycles 
with  associated  confidence. 

■  Failure  Risk  with  associated  confidence. 

■  Time  to  Specific  Maintenance  Action. 


Figure  10  -  Avionics  Problem  Classes  and 
Class  4  for  Prognostics 


IX.  Summary  and  Future  Work 

Impact  identified  evidence  sources  and  developed 
reasoners  with  open  data  interfaces  specific  to  avionics 
health  management  and  related  the  use  of  such  within  a 
streamlined  maintenance  operational  concept.  Several 
prototypes  were  developed  that  could  be  further 
implemented  to  address  specific  diagnostic  activities. 

Impact  and  Honeywell  are  currently  planning  a  more 
detailed  Phase  II  effort  with  specific  implementation  of 
some  of  the  prototypes  discussed  in  this  paper.  Specifically, 
there  exists  the  potential  for  a  generic  system  reasoner  to  be 
developed  using  a  Bayesian  or  Dempster-Shafer  approach. 
The  Evidence-based  Reasoner  includes  the  means  to  adjust 
the  FM  rank  based  upon  multiple  sources  including  failure 
rates,  usage,  and  technician  input.  The  open  data 
architecture  also  allows  Impact  the  opportunity  to  generate 
OS  A  wrappers  for  both  legacy  and  new  systems. 
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